Building Enclave-Native Storage Engines for Practical Encrypted Databases
タイトル: Building Enclave-Native Storage Engines for Practical Encrypted Databases
著者: Yuanyuan Sun, Sheng Wang, Huorong Li, Feifei Li(Alibaba Group)
TL;DR
セキュリティ、性能、機能のトレードオフをより現実的に考慮しなければならない暗号化データベースにおいて、どのようにして機密性を実現するかという問いに対し、実用的なトレードオフを実現する暗号化ストレージエンジン「Enclage」を提案
EnclageはIntel SGXを用いており、ページレベルの暗号化、エンクレイブ間の相互作用低減、階層型メモリバッファなど多くのEnclave固有の設計を採用しており、高レベルのセキュリティ保証と高性能を同時に実現 Enclageは多くの暗号化データベースで一般的に採用されているストレージ設計よりもパフォーマンス性が高い
本文
Trusted Exection Environment(TEE)のおかげで、顧客のデータをクラウド上で機密性を保ちながら処理できる暗号化データベースをEnclave内に構築することが可能になり、いくつかのエンクレイブベースの暗号化データベースが登場している。だが、セキュリティ、性能、機能のトレードオフが考慮されていないものが多く、実用的ではない(実運用上のデータ機密性を提供するという観点でも厳しい)。 SGXベースの暗号化データベースの課題(TEE技術の性質とSGXでの実装による制限)
SGXベースの暗号化データベースの多くは、TEEの性質に合わせた設計を実現するより既存のデータベースをそのままEnclave内で実行する形である。
Enclave内のメモリ領域の制限
データベースは、多くのコンポーネント(バッファプールとか)や操作(結合など)などの処理が本質的にメモリを消費する構造になっており、既存の設計では性能が低下する可能性がある
Enclaveとのやりとりによる膨大なコスト
ECall/OCallのコストが高すぎる(15000CPUサイクル)
頻繁にコンテキストスイッチを行うと性能が低下する
TCBサイズ問題
これらを解決するために暗号化データベースにおける実現可能なデザインパターンを分類し、それらを組み合わせ・実装することでセキュリティ、性能、機能における実用的なトレードオフを実現する暗号化ストレージエンジンを提案する論文
特徴
Enclaveで実行されるのはインデックスストアとテーブルストアのみ(検索エンジンとストレージはEnclave外)
cipepser.icon 外部ストレージへのアクセスパターンが推測できてしまうような?
Enclave Index(インデックスストア)
cipepser.icon みんなのデータ構造でやった、blockサイズを数百〜数千にするとB+木の内部ノードは全体の0.1〜1%程度に抑えられる話ですね
エントリー検索と更新など
データは平文
ほとんどのEPCをEnclave Indexが使用
Enclage Strore(テーブルストア)
レコードの読み書きなど(データは外部ストレージなどに保存)
データは暗号化される
Enclave実行時と非Enclave実行時の不要なコンテキストスイッチを避ける
Enclaveへのエントリー数は1回のみになり、外部とのやりとり(I/O)も最小化
頻繁にアクセスされるページをEnclave内にキャッシュとして持つ。そうすることでencrypt/decryptのオーバーヘッドによる負担を軽減
Architecture
https://gyazo.com/2997062f110c5e8f064885ee76e5c2c5
(論文より引用)
jkcomment.icon 図はこれしかないなー
用語
EBuffer
保護されていないHost MemoryとEnclave Memory間のPage転送管理
MBuffer
Host Memoryと外部ストレージ間のPage転送管理
実行ロジックの一部をEnclaveで実装
EnclaveはHost Memoryに直接アクセスでき、PageがすでにHost Memoryにあり、その位置をEnclaveに知られている場合はOCallなしでMBufferからPageが取得できる。つまり、不要なOCallを避けることができる
処理の流れ
insert
新しいレコードは、まずheap fileに追加され、rid(レコード識別子)が割り当てられる。このridを使ってStoreから対応するレコードを取得。Enclave Indexには各レコードのIndex key(インデックス対象列の値)とridのpairが格納される。ridにはレコードの位置(ページID、offset、レコード長)が含まれており、レコードの取得、更新、削除などに使われる
select
ISearch(E(key)) -> EBuffer確認 -> データが存在しない場合、MBuffer確認 -> データが存在しない場合、OCallで外部ストレージ参照 -> OE(rid)で結果を返す
デザインパターン分類
https://gyazo.com/45e67efacc184a74f96fbce5969a8998
(論文より引用)
暗号化粒度
item-level: インデックスキーやカラムなど
page-level: データページなど
エンクレイブ内の実行ロジック
メモリアクセス粒度
エンクレイブのメモリ使用量
レコードのアイデンティティ保護
jkcomment.icon Enclageはどちらかというとセキュリティと性能に中心をおいた設計だなー
性能評価
https://gyazo.com/7388494cad8ca8e35d8810da5f1549e6
cipepser.icon encryptedじゃないDBとの比較とかありました?
jkcomment.icon そうですね。この論文の比較対象は暗号化データデースのみでした
https://gyazo.com/60fa4deb69fb005150daa28565cc1e13
(論文より引用)
比較対象
Baseline
ItemEnc
Baselineの実行を完全にEnclave内にしたもの
Throughput
Baselineより10.85倍、ItemEncより8.32倍
Response
スイッチとスイッチレスの両方のモードでワークロードAの スイッチレスモードでは、平均レイテンシが51.8%改善され、99-percentileのレイテンシは37.5%改善されている